Currently 3rd Generation Partnership Project (3GPP) User Data Convergence (UDC, 3GPP terminology) is being standardized for coming 3GPP Release 9. A new architecture illustrated in FIG. 1 in the Core Network (CN) 100 is proposed where subscriber service related data and business logic of different network elements are separated. This way, a User Data Repository 102 (UDR, 3GPP terminology) is used as a centralized database, so that the different application front-ends 106-110 can access the user data (through the new “Ud” reference point 112). A requirement is to minimize the impact on existing network by introducing UDC.
Functional entities, such as the Home Location Register (HLR)/Home Subscriber Server (HSS), Authentication Centre (AuC), Application Servers, Provisioning system, etc., when the UDC architecture is applied, keep the application logic, but they do not locally store user data permanently. These data-less functional entities are collectively known in the UDC architecture as application front-ends (FEs) 106-110.
Lightweight Directory Access Protocol (LDAP, Internet Engineering Task Force (I ETF) standard) has been nowadays agreed (stage-3 activities are in progress) as the data-access protocol to be used in the Ud interface for CRUD (Create, Read, Update, Delete) operations.
According to UDC architectural principles, each application-FE can manage any subscriber-related request at any time. And for many applications more than one application-related procedure (i.e. operation) can be managed towards the exact same subscriber concurrently (i.e. in parallel). In consequence, there can be situations in which two (or more) different application-FE instances are managing two (or more) different application-related requests for the exact same piece of data (i.e. the exact same subscriber directory entries/attributes managed in UDR).
For example, one 3G mobile subscriber is moving across the Home network (so a “Location Update” procedure is issued internally in the Core Network to update the subscriber location) and, at the same time, the same subscriber is invoking a “subscriber procedure” to change the redirection number for the (previously activated) “Call Forwarding on No Reply” Supplementary Service.
In the previous example two different HLR-FE instances (the one managing the issued “Mobile Application Part (MAP, SS7 stack) Location Update” procedure and the one managing the invoked subscriber-procedure) are trying to access and modify the exact same piece of data in UDR at the same/nearly time.
There are many other network use-cases in which this kind of situations can happen. According to a first example, a Provisioning-FE entity may try to update a subscriber profile (as a result of a provisioning order received from Customer Administration System (CAS)) and, at the same time, an application-FE is trying to update the exact same piece of data (or some common part). According to a second example, two different FE instances from two different applications may try to modify some common (to both applications) data for the same subscriber profile.
It is noted that the first Use Case (UC) in the previous list of examples (involving a Provisioning-FE instance) is maybe the most generic UC to happen (as it is independent of an application allowing—or not—to process two or more procedures related to the exact same subscriber in parallel from two or more different FE instances).
In all these kind of situations “data consistency” problems could arise if some mutual-exclusion mechanism is not guaranteed in UDR, as better shown in a sequence diagram of FIG. 2 (which is taken as a graphical example):
In particular, such a problematic situation may arise from two clients such as an HLR-FE 206 and a Provisioning-FE 208 both requesting modification of a data entry at a directory database such as an UDR 202. The steps of the exemplary sequence diagram of FIG. 2 are as follows:
In a first step 216, the HLR-FE 206 receives a MAP Location Update particularly from a subscriber. In a further step 218, the HLR-FE 206 requests to read a subscriber profile associated with the subscriber, and the HLR-FE 206 sends a respective LDAP Search Request to the UDR 202. Accordingly, the UDR 202 sends respective profile data to the requesting HLR-FE 206. Thereupon, in a further step 220, the HLR-FE 206 executes an application related logic, and particularly may process the received profile data of the subscriber.
In a next step 222, the Provisioning-FE 208 receives a Provisioning order particularly from CAS. In a next step 224, the Provisioning-FE 208 requests to read the subscriber profile associated with the subscriber, and sends a respective LDAP Search request to the UDR 202. Accordingly, the UDR 202 sends respective profile data to the requesting Provisioning-FE 206. Thereupon, in a step 226, the Provisioning-FE 206 executes an application related logic and particularly may process the received profile data of the subscriber.
In a step 228, the Provisioning-FE 208 requests to update the subscriber profile stored at the UDR 202 by sending a respective LDAP Modify Request. Accordingly, the UDR 202 updates the subscriber profile, and sends information about the update process, particularly an updated subscriber profile, to the Provisioning-FE 208.
In a step 230, the HLR-FE 206 also requests to update the subscriber profile stored at the UDR 202 by sending a respective LDAP Modify Request. Accordingly, the UDR 202 also updates the subscriber profile, and sends information about the update process, particularly an updated subscriber profile, to the Provisioning-FE 208.
Thus, in step 228 of FIG. 2 the subscriber profile is updated (by the Provisioning-FE 208), so the profile managed by HLR-FE instance 206 (read in step 216) is an “old” one from that moment on. The final update operation issued by the HLR-FE 206 in step 230 does not take into account the introduced changes in step 228, so there is a data-consistency risk (e.g. some attribute values introduced in step 228 could be overwritten in step 230; alternatively or in addition, in steps 228 and 230 different data—but still related—may be updated, so data-consistency at application level can be “damaged”).
To avoid these situations some solutions have currently been proposed for LDAP, which however, suffer from a common problem as all of them require a special behavior in the LDAP clients to help the LDAP Directory Server (i.e. UDR) to detect the update-collision (so the mutual-exclusion algorithm associated to each of these solutions can be triggered). In all these solutions the LDAP server (i.e. the one that must assure data consistency properties for the data it is storing) is not the entity deciding when the mutual-exclusion mechanism must be triggered; in the end, it is the application-FE the entity deciding it (providing also the required data to execute the associated mutual-exclusion algorithm). A drawback may be that these solutions may only be valid for walled-garden environments, i.e. those in which both the LDAP directory server and the LDAP client belongs to the same operator domain due to the strict control on the LDAP client behavior required from the “solution owner”. A further drawback may be that these solutions are error-prone solutions as they depend on the right behavior for each individual LDAP client. Even another drawback may be that an integration of Application-FEs in a deployed layered architecture may be difficult, costly, and time-consuming, because the LDAP clients included in those FEs must be adapted to follow the required right behavior. Furthermore, these solutions may come along with unsolved vendor interoperability issues and further barriers to solve when trying to integrate a deployed UDR with 3PP applications-FEs.